wolfHAL/timer/systick.h:1

• This changes the public header API from SysTick_* to whal_SysTick_* (the old symbols/prototypes are removed). If external users (or downstream boards) were calling SysTick_Init/Deinit/... directly, this is a breaking change. Consider adding compatibility aliases in the header (e.g., #define SysTick_Init whal_SysTick_Init, etc.) or retaining the old prototypes as deprecated wrappers to avoid breaking downstream code.
  wolfHAL/timer/systick.h:1
• This changes the public header API from SysTick_* to whal_SysTick_* (the old symbols/prototypes are removed). If external users (or downstream boards) were calling SysTick_Init/Deinit/... directly, this is a breaking change. Consider adding compatibility aliases in the header (e.g., #define SysTick_Init whal_SysTick_Init, etc.) or retaining the old prototypes as deprecated wrappers to avoid breaking downstream code.
  wolfHAL/timer/systick.h:1
• This changes the public header API from SysTick_* to whal_SysTick_* (the old symbols/prototypes are removed). If external users (or downstream boards) were calling SysTick_Init/Deinit/... directly, this is a breaking change. Consider adding compatibility aliases in the header (e.g., #define SysTick_Init whal_SysTick_Init, etc.) or retaining the old prototypes as deprecated wrappers to avoid breaking downstream code.
  wolfHAL/timer/systick.h:1
• This changes the public header API from SysTick_* to whal_SysTick_* (the old symbols/prototypes are removed). If external users (or downstream boards) were calling SysTick_Init/Deinit/... directly, this is a breaking change. Consider adding compatibility aliases in the header (e.g., #define SysTick_Init whal_SysTick_Init, etc.) or retaining the old prototypes as deprecated wrappers to avoid breaking downstream code.
  wolfHAL/timer/systick.h:1
• This changes the public header API from SysTick_* to whal_SysTick_* (the old symbols/prototypes are removed). If external users (or downstream boards) were calling SysTick_Init/Deinit/... directly, this is a breaking change. Consider adding compatibility aliases in the header (e.g., #define SysTick_Init whal_SysTick_Init, etc.) or retaining the old prototypes as deprecated wrappers to avoid breaking downstream code.
  src/irq/cortex_m4_nvic.c:1
• These functions were changed from static to external unconditionally. If the project ever needs to compile/link multiple NVIC implementations (or otherwise wants to keep these internal when not mapping), this increases the chance of symbol collisions and expands the exported surface area. A more robust pattern is to keep these static when WHAL_CFG_IRQ_API_MAPPING_NVIC is not defined, and only make them external in the mapping configuration (e.g., via a WHAL_API/WHAL_LOCAL macro or #ifdef around the static).
  src/irq/cortex_m4_nvic.c:1
• These functions were changed from static to external unconditionally. If the project ever needs to compile/link multiple NVIC implementations (or otherwise wants to keep these internal when not mapping), this increases the chance of symbol collisions and expands the exported surface area. A more robust pattern is to keep these static when WHAL_CFG_IRQ_API_MAPPING_NVIC is not defined, and only make them external in the mapping configuration (e.g., via a WHAL_API/WHAL_LOCAL macro or #ifdef around the static).
  src/irq/cortex_m4_nvic.c:1
• These functions were changed from static to external unconditionally. If the project ever needs to compile/link multiple NVIC implementations (or otherwise wants to keep these internal when not mapping), this increases the chance of symbol collisions and expands the exported surface area. A more robust pattern is to keep these static when WHAL_CFG_IRQ_API_MAPPING_NVIC is not defined, and only make them external in the mapping configuration (e.g., via a WHAL_API/WHAL_LOCAL macro or #ifdef around the static).
  src/irq/cortex_m4_nvic.c:1
• These functions were changed from static to external unconditionally. If the project ever needs to compile/link multiple NVIC implementations (or otherwise wants to keep these internal when not mapping), this increases the chance of symbol collisions and expands the exported surface area. A more robust pattern is to keep these static when WHAL_CFG_IRQ_API_MAPPING_NVIC is not defined, and only make them external in the mapping configuration (e.g., via a WHAL_API/WHAL_LOCAL macro or #ifdef around the static).
  wolfHAL/platform/st/stm32wb55xx.h:1
• With direct API mapping enabled, many driver vtables are compiled out (e.g., whal_Stm32wbUart_Driver), but _DRIVER macros like this remain unconditionally defined and will expand to undefined symbols if accidentally used—leading to link-time failures that can be hard to diagnose. Consider making _DRIVER macros conditional on the corresponding mapping flag (or defining them to NULL / a sentinel and documenting it), so misuse is caught earlier and configurations are less error-prone.
  wolfHAL/uart/stm32wb_uart.h:1
• The closing #endif comment doesn’t match the actual condition (it references WHAL_CFG_UART_API_MAPPING, but the guard is a multi-flag condition). Updating the comment to reflect the real condition would reduce confusion during maintenance/debugging.
  wolfHAL/uart/stm32wb_uart.h:1
• The closing #endif comment doesn’t match the actual condition (it references WHAL_CFG_UART_API_MAPPING, but the guard is a multi-flag condition). Updating the comment to reflect the real condition would reduce confusion during maintenance/debugging.
  src/uart/stm32f4_uart.c:1
• These async stubs are always compiled, even when WHAL_CFG_UART_API_MAPPING_STM32F4 is not enabled. In non-mapped builds, the generic dispatch likely determines async availability via vtable pointers, so these standalone functions can become dead/undocumented API surface. Consider wrapping these stubs in the same mapping guard used for renaming (like the STM32WB polled UART does), or explicitly documenting why they are intentionally exported even in non-mapped builds.

wolfHAL/uart/uart.h:1

• These comments state SendAsync/RecvAsync are NULL if unsupported, but several polled drivers in this PR populate these with stub functions that return WHAL_ENOTIMPL. Please align the contract: either (a) keep these pointers NULL in vtable-based builds and rely on the dispatch layer returning WHAL_ENOTIMPL, or (b) update the comment/API documentation to explicitly allow non-NULL stubs for unsupported async.
  src/uart/stm32wb_uart.c:1
• The async stub functions are always compiled and wired into the vtable, even in non-mapped (vtable-dispatch) builds. This adds code size and contradicts the header comment that async pointers are NULL when unsupported. Recommendation: only compile these stubs (and assign them) when direct API mapping is enabled; otherwise set .SendAsync = NULL and .RecvAsync = NULL so the dispatch layer returns WHAL_ENOTIMPL without extra call overhead. This same pattern appears in other UART drivers added in this PR.
  src/uart/stm32wb_uart.c:1
• The async stub functions are always compiled and wired into the vtable, even in non-mapped (vtable-dispatch) builds. This adds code size and contradicts the header comment that async pointers are NULL when unsupported. Recommendation: only compile these stubs (and assign them) when direct API mapping is enabled; otherwise set .SendAsync = NULL and .RecvAsync = NULL so the dispatch layer returns WHAL_ENOTIMPL without extra call overhead. This same pattern appears in other UART drivers added in this PR.
  wolfHAL/uart/stm32wb_uart.h:1
• The #endif comment references WHAL_CFG_UART_API_MAPPING, but the guard condition checks several mapping macros. Please update the comment to match the actual condition (e.g., mention the specific macros or use a generic description like /* UART direct API mapping disabled */) to avoid confusion during future edits.
  wolfHAL/uart/stm32wb_uart.h:1
• The #endif comment references WHAL_CFG_UART_API_MAPPING, but the guard condition checks several mapping macros. Please update the comment to match the actual condition (e.g., mention the specific macros or use a generic description like /* UART direct API mapping disabled */) to avoid confusion during future edits.
  wolfHAL/spi/stm32wb_spi.h:1
• The #endif comment (!WHAL_CFG_SPI_API_MAPPING) doesn't match the actual condition (WHAL_CFG_SPI_API_MAPPING_STM32WB and WHAL_CFG_SPI_API_MAPPING_STM32C0). Update the comment so it reflects the real preprocessor guard.
  wolfHAL/spi/stm32wb_spi.h:1
• The #endif comment (!WHAL_CFG_SPI_API_MAPPING) doesn't match the actual condition (WHAL_CFG_SPI_API_MAPPING_STM32WB and WHAL_CFG_SPI_API_MAPPING_STM32C0). Update the comment so it reflects the real preprocessor guard.